Non-real-time selection of distributed DHO nodes

ABSTRACT

The present invention relates to an arrangement adapted to be located in a network node, e.g. in a RNC, in a mobile communication network. The arrangement selects at least one diversity handover, DHO, node, that is to perform macro diversity functions, amongst the nodes of the mobile communication network comprising macro diversity functionality means. The selection is based on base station combinations of said mobile communication network. The arrangement comprises means for retrieving at least one DHO node, that is to perform macro diversity functions, from a database comprising base station combinations of said mobile communication network and a pre-calculated DHO node selection for each such base station combination. The present invention also relates to said database. The database comprises means for storing base station combinations of said mobile communication network and means for storing a pre-calculated Diversity Handover node selection for each such base station combination.

FIELD OF THE INVENTION

The present invention relates to arrangements in a cellular mobilecommunication network comprising means for handling macro diversityfunctions, and in particular to arrangements for determining a node thatis to perform the macro diversity functions.

BACKGROUND OF THE INVENTION

Third generation (3G) mobile communication systems (e.g. UniversalMobile Telecommunications System (UMTS)) shall offer high quality voiceand data services for mobile users. The systems shall also provide highcapacity and universal coverage. In some situations that may however bedifficult to fulfil, due to unreliable radio channels. One promisingtechnique to combat link reliability problems over the radio interfaceis macro diversity techniques. Macro diversity should however also beseen as an inherent consequence of using Code Division Multiple Access(CDMA) as the multiple access technique in a cellular network. CDMA isan interference limited technology. That is, it is the interference in acell that sets the upper limit for the cell's capacity. To keep theinterference as low as possible it is essential that the base stationcontrols the output power of the radio transmitters of the mobileterminals in the cell, i.e. fast and efficient power control isessential. As a mobile terminal moves towards the periphery of a cell ithas to increase the power of its radio transmission in order for thebase station to be able to receive the transmitted signal. Likewise, thebase station has to increase the power of its radio transmission towardsthe mobile terminal. This power increase has a deteriorating effect onthe capacity of both the mobile terminal's own cell and the neighboringcell(s) which the mobile terminal is close to. Macro diversity is usedto mitigate this effect. When the mobile terminal communicates via morethan one base station, the quality of the communication can bemaintained with a lower radio transmission power than when only a singlebase station is used. Thus, macro diversity is both a feature raisingthe quality of unreliable radio channels and a necessity that isrequired in order to overcome an inherent weakness of CDMA basedcellular systems.

The present invention relates to arrangements in a radio access networkof a cellular mobile network comprising means for handling macrodiversity functions. An example of such a radio access network is theUMTS terrestrial radio access network (UTRAN). The UTRAN is illustratedin FIG. 1 and comprises at least one Radio Network System (RNS) 100connected to the Core Network (CN) 200. The CN is connectable to othernetworks such as the Internet, other mobile networks e.g. GSM systemsand fixed telephony networks. The RNS 100 comprises at least one RadioNetwork Controller (RNC) 110. Furthermore, the respective RNC 110controls a plurality of Node-Bs 120, 130 that are connected to the RNCby means of the Iub interface 140. Each Node B covers one or more cellsand is arranged to serve the User Equipment (UE) 300 within saidcell(s). Finally, the UE 300, also referred to as mobile terminal, isconnected to one or more Node Bs over the Wideband Code DivisionMultiple Access (WCDMA) based radio interface 150. The network of FIG. 1is also referred to as a WCDMA network and is based on the WCDMAstandard specified by the 3:rd Generation Partnership Project (3GPP).

Macro diversity implies in this description that the mobile terminalcommunicates with more than one base station simultaneously, i.e. thesame data flow is transmitted to/from the mobile terminal from/to atleast two different base station. When two or more base stationsreceive/transmit the same data flow, the data flows are combined/splitat a higher node, referred to as a diversity handover node (DHO node).The DHO node may be a RNC, or a Node B (or another type of node such asa specialized DHO node or a new type of control node) when a distributedmacro diversity scheme is used as explained below.

In current UTRANs macro diversity is realized through macro diversityfunctionality (i.e. DHO functionality) in the RNCs. The standard allowsDHO functionality in both the serving RNC (SRNC) and the drift RNC(DRNC), but many vendors have chosen not to use the possibility tolocate DHO functionality in the DRNC. The standard also allows up to sixmacro diversity legs, i.e. six Node Bs in the active set, but productsmay be limited to be implemented such that only two and three leg macrodiversity is possible, i.e. maximum three Node Bs in the active set. Thereason for limiting the active set to three Node Bs is that very littlegain is expected from additional legs.

Thus, in existing macro diversity solutions the user data is transportedin multiple separate data flows, one for each macro diversity leg, allthe way between the RNC and the Node Bs. This consumes costlytransmission resources in the UTRAN transport network. A moretransmission efficient way to realize the macro diversity in a UTRAN isto distribute the DHO functionality to the Node Bs (and the RNCs). Theresult is not only distributed macro diversity functionality but alsohierarchical macro diversity functionality, since more than two macrodiversity legs may result in more than one DHO node. The benefits thatcan be achieved depend on the topology of the UTRAN transport network.FIGS. 2 and 3 illustrate two cases when the distributed DHOfunctionality is beneficial compared to having the DHO functionalityonly in the RNC. It should be noted that the DHO functionality couldalso be distributed to other types of nodes than Node Bs (base stations)and RNCs, e.g. specialized DHO nodes or new types of control nodes.Having noted this, the further description of the present inventionwill, for the sake of clarity, focus on RNCs and Node Bs (base stations)as DHO nodes, but the present invention is applicable also when othertypes of DHO nodes are used.

Mechanisms for such a distributed macro diversity scheme have beendescribed in WO2005/62654, WO2005162655 and WO2005/62495. The scheme,which is controlled by the SRNC, includes:

-   -   mechanisms for selection of the Node Bs that are to perform the        macro diversity functions (splitting and combining), i.e. the        distributed DHO nodes;    -   mechanisms for directing the data flows between the selected DHO        nodes and providing the DHO nodes with the information that they        need in order to perform the splitting and combining; and    -   a timing scheme to handle the trade off between delay and data        loss.

The present invention deals with the first of the above three items,i.e. selection of DHO nodes, i.e. to select which of the DHO enablednodes that is to perform the macro diversity function. A number ofreal-time DHO node selection schemes are described in WO2005/62654 andWO2005/62655. The major parts of the invention can be used also togetherwith other DHO node selection schemes than the ones described inWO2005/62654 and WO2005/62655. Common for the DHO node selection schemesis that they rely on topology information from the transport networklayer to select the most appropriate DHO nodes. An RNC can retrieve thenecessary topology information in four different ways:

-   1. Through manual or semi-automatic management operations.-   2. Via a link state routing protocol.-   3. Using a traceroute mechanism that allows the RNC to discover the    hop-by-hop route to each Node B in an IP UTRAN.-   4. Through signaling an RNC may possibly retrieve topology    information from other RNCs to cater for the inter-RNS case (if    applicable).

The traceroute method may be the most attractive one, but it only worksin IP based UTRANs.

The retrieved topology information is stored in a topology database inthe RNC which is updated when/if the topology of the UTRAN changes. Theinformation in the topology database includes (at least):

-   -   The hop-by-hop route from the RNC to each Node B in the RNS and        possibly to some Node Bs in neighboring RNSs to cater for        inter-RNS soft handover cases.    -   A delay metric for each hop in a route.    -   Some sort of generic cost metric for each hop in a route. The        generic cost metric reflects the operator's relative willingness        to use the link for data transport. In the simplest case the        delay metric is used as the generic cost metric.    -   Information about which nodes that are DHO enabled, i.e. the        Node Bs comprising macro diversity function. However, this        information does not have to be included in the topology        database as such. It may alternatively be stored elsewhere in        the RNC.

The goal of a DHO node selection algorithm is to select DHO nodes in away that minimizes the accumulated generic cost metrics for the all themacro diversity legs put together with the condition that for none ofthe resulting data paths is the resulting path delay allowed to exceed amaximum delay value defined for the UTRAN.

The above mentioned real-time DHO node selection algorithms use theinformation in the topology database to create a “route tree” that isthe basis for the DHO node selection for a certain macro diversityconfiguration i.e. for a certain combination of Node Bs for a macrodiversity connection. Then a set of preliminary DHO nodes are selectedand together with the SRNC, any involved non-DHO node Node Bs and therelative interconnections of the nodes they form a conceptual “DHO nodetree”.

Then the RNC checks that the resulting path delay will not exceed themaximum allowed path for any of the macro diversity legs. If a pathdelay is too large, DHO nodes are removed until the path delay isacceptable for all macro diversity legs. Alternatively the delay checksmay be integrated in the selection of the preliminary DHO nodes.

The real-time DHO node selection is executed when needed, i.e. when themacro diversity configuration of a connection is established or changed(i.e. when a Node B/base station is added or removed from thecombination of Node Bs/base stations used for a macro diversityconnection).

Although the above-mentioned existing DHO node selection schemes work,they do have certain disadvantages. They are all calculation-intensiveprocedures that are to be executed under a real-time pressure.Therefore, the existing DHO node selection schemes may adversely affectthe real-time properties of connection establishment i.e. introduceincreased delay and may therefore delay changes in the macro diversityconfiguration of a connection i.e. additions or removals of Node Bstaking part in the macro diversity connection.

Another aspect of this problem is that the introduced increased delaylimits the complexity that can be allowed for a real-time DHO nodeselection scheme and thus limits the potential accuracy that the schemecan achieve, i.e. how close its DHO node choices are to thetheoretically ideal choices.

The problems with the introduced increased delay may be addressed byadding more computation resources in the RNC, but that would insteadunnecessarily increase the cost of the node.

SUMMARY OF THE INVENTION

As stated above, it is desired to achieve a solution that provides areal time DHO node selection scheme that does not introduce delay.

Therefore, the object of the present invention is to achieve anarrangement that avoids delay during the real time DHO node selection.

The object of the present invention is achieved by the arrangementsaccording to the independent claims.

Preferred embodiments are defined by the dependent claims.

The arrangement according to the present invention is adapted to belocated in a network node, e.g. in an RNC, in a mobile communicationnetwork such as a WCDMA network or an evolved version thereof forselecting at least one diversity handover, DHO, node, that is to performmacro diversity functions, amongst the nodes of the mobile communicationnetwork comprising macro diversity functionality means. The selection isbased on base station combinations of said mobile communication networkand the arrangement comprises means for retrieving at least one DHOnode, that is to perform macro diversity functions, from a databasecomprising base station combinations of said mobile communicationnetwork and a pre-calculated DHO node selection for each such basestation combination.

The database according to the present invention is adapted to be locatedin a network node in a mobile communication network, and comprises meansfor storing base station combinations of said mobile communicationnetwork and means for storing a pre-calculated Diversity Handover nodeselection for each such base station combination.

The nodes comprising macro diversity functionality means are preferablybase stations and nodes controlling base stations.

According to a preferred embodiment, the arrangement comprises means forlimiting the number of base station combinations in the database basedon the usefulness of the base station combinations, e.g. based onneighbor relations of the base stations within the base stationcombination or based on previous actual use of the base stationcombination.

According to one embodiment the arrangement comprises means for updatingthe base station combinations to be included in the database. Theupdating may be triggered by a configuration change of the mobilecommunication network and performed continuously as a backgroundprocess. Furthermore, the updating may be based on new base stationneighbor relations. In addition, the arrangement comprises means forremoving base station combinations from the database by time stampingeach used base station combination such that the last time thecombination was used is indicated.

According to a further embodiment, the arrangement comprises means forupdating the pre-calculated DHO node selections for the base stationcombinations stored in the database. Means may also be provided forperforming continuous updating of the pre-calculated DHO node selectionsfor the base station combinations in the database as a backgroundprocess. The updating may also be triggered by a configuration change ofthe mobile communication network.

According to further embodiments, the arrangement comprises means fortemporarily allocating more computation resources to the updating whenthe configuration of the mobile communication network changes and meansfor interrupting updating of the pre-calculated DHO node selection of abase station combination in the database if it is determined that theupdating will not change the DHO node selection of the base stationcombination. Moreover, means for storing a tree of routes formed by theroute from the network node to each of the base stations in the basestation combination and means for comparing the stored tree of routeswith a new tree of routes derived from information from an updatedtopology database may also be provided. The tree of routes may be storedby means of a signature or digest. The means for interrupting maycomprise further means for updating of the pre-calculated DHO nodeselection for a base station combination in the database, if said newtree of routes is different from said stored tree of routes and/orfurther means for updating of the pre-calculated DHO node selection fora base station combination in the database, if said new tree of routesis different from said stored tree of routes. A timestamp associatedwith the route from the network node to each base station may be storedby the arrangement, wherein the timestamp indicates the last time whenthe route was updated, e.g. the last time the DHO node selection for thebase station combination was calculated.

According to a further embodiment, means are provided for triggeringupdating of the DHO node selection for a base station combination in thedatabase by a configuration change of the mobile communication networkif it is determined that the updating will change the DHO node selectionfor the base station combination. Moreover, means may also be providedfor temporarily allocating more computation resources to the updating ifit is determined that the updating will change the DHO node selection ofthe base station combination in the database.

According to a further embodiment, the arrangement comprises means forstoring a timestamp that indicates the time of the last relevant eventin the mobile communication network, wherein the last relevant event isa type of events that may affect the DHO node selection of base stationcombinations in the database. Means for storing a timestamp associatedwith each base station combination in the database may be provided,wherein the timestamp indicates the last time the DHO node selection forthe base station combination was calculated. The DHO node selection of abase station combination in the database may be avoided, unless thetimestamp associated with the base station combination indicates a latertime than said timestamp that indicates the time of the last relevantevent in the mobile communication network.

According to a further embodiment, the arrangement comprises means fortime stamping a base station wherein the timestamp indicates when thelast event occurred that may affect the DHO node selection of basestation combinations that include said base station in the database.

According to a yet further embodiment means for temporarily disablingmacro diversity functionality means after events that affect the contentof the database of base station combinations are provided.

An advantage with the present invention is that it relieves thecalculation-intensive DHO node selection process from the real-timepressure.

A further advantage is that it replaces the real-time DHO node selectioncalculations with a database lookup, thereby eliminating the increasedsetup delay (and soft handover delay) for macro diversity connectionsthat would otherwise be introduced by a distributed macro diversityscheme. Also, it allows more advanced and computation-demanding DHO nodeselection algorithms to be used, due to the relaxed real-timerequirements.

A further advantage is that through various optimizations according tothe present invention, the required resources, in terms of memory andcomputation power, for creation, maintenance and usage of the DHO nodeselection database, can be limited to rather insignificant numbers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example of an existing mobile cellular network.

FIG. 2 illustrates the potential transmission savings in an example withcascaded Node Bs.

FIG. 3 illustrates the potential transmission savings in an example witha transport network with a tree topology.

FIG. 4 illustrates the arrangement according to the present invention.

FIG. 5 illustrates the number of possible combinations of two basestations as a function of the total number of base stations in the RNS.

FIG. 6 illustrates the number of possible combinations of three basestations as a function of the total number of base stations in the RNS.

FIG. 7 illustrates the number of realistic combinations of two or threebase stations as a function of the total number of base stations in theRNS.

FIG. 8 illustrates the number of possible and the number of realisticcombinations of two or three base stations as a function of the totalnumber of base stations in the RNS.

DESCRIPTION OF THE INVENTION

The present invention will be described more fully hereinafter withreference to the accompanying drawings, in which preferred embodimentsof the invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theembodiments set forth herein; rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope of the invention to those skilled in the art.

The present invention relates to macro diversity in a cellular network.Most of the mechanisms of the present invention are not limited to a3GPP UTRAN, but could also be used in other networks employing macrodiversity. Therefore the solution is described using the more generalterm “base station” rather than the UTRAN specific term “Node B”. In aUTRAN context the terms “base station” and “Node B” are regarded asequivalent. However, the UTRAN specific terms “RNC” and “RNS” are keptin lack of well-established equivalent general terms.

Instead of performing the DHO node selection calculations in real-timeon demand, the DHO node selection for each macro diversity configurationi.e. each combination of base stations is calculated in advanced andstored in a database together with the base station combinationaccording to the present invention. The database is preferably locatedin an RNC. It should be noted that the present invention is not limitedto the situation when the database is located in the RNC, even if thatis the case in the examples in the following description. Hence adatabase is formed that contains all or a subset of macro diversityconfigurations in the RNS of said RNC and their respectivepre-calculated DHO node selection. That implies that each entry of thedatabase contains a base station combination and the associated DHO nodetree produced by a DHO node selection algorithm. Thus an arrangement isprovided by the present invention that makes it possible to retrieve theDHO node(s), i.e. the DHO enabled base station(s) (and/or other types ofnode(s)), that is(are) to perform macro diversity functions, from thedatabase comprising base station combinations and a pre-calculated DHOnode selection for each such base station combination. Such anarrangement is illustrated in FIG. 4. The arrangement 400 comprises theabove described database 410 and means 420 for retrieving the DHOnode(s) that is(are) to perform macro diversity functions from thedatabase to a DHO node selection unit 430. The arrangement is located ina network node, preferably a node adapted to control radio base stationssuch as a RNC. Further, the present invention also relates to a databaseadapted to be located in the network node. The database comprises meansfor storing base station combinations and means for storing apre-calculated DHO node selection for each such base stationcombination. Each RNC is responsible for its own database, whichcontains only base station combinations that belong to the RNC itselfi.e. only intra-RNS macro diversity cases are considered. The DHO nodeselections may be calculated using the same algorithms as in theexisting solutions.

The nodes in the database are represented in the same way as in thetopology database and as described for the DHO node selection algorithmsin WO2005/62654, e.g. by using IP addresses.

Subsequently, when a DHO node selection (in the form of a DHO node tree)is needed, because of a macro diversity connection setup or a macrodiversity configuration change, the RNC simply retrieves the DHO nodefrom the database according to the present invention, using theconcerned base station combination as the key.

Configuring the database may be a huge task, due to the potentially verylarge number of base station combinations. Manual configuration is not areasonable alternative. Creation and maintenance of the database must beautomated. Thus, the RNC itself, or alternatively an O&M tool, maypreferably generate the base station combinations to be included in thedatabase, add or remove combinations as needed.

Consequently it is not enough to calculate the DHO node selectiondatabase only once. On the contrary it has to be continuously updated inorder to reflect the changes in base station deployment and transportnetwork topology. Therefore, the RNC continuously refreshes thedatabase, recalculates each DHO node selection result, adds entries withnew base station combinations containing newly deployed base stationsand removes entries with base station combinations containing removedbase stations.

Recalculation of the DHO node selection results should preferably beperformed as a low-priority background task (or by other means separatedfrom computations with higher priority), so as to not interfere withhigh-priority real-time tasks like Radio Resource Control (RRC)signaling, connection handling and traffic execution.

It would also be possible to run DHO node selection recalculations onlyduring periods of low load, e.g. during nighttime.

When a new base station is added, the RNC calculates the resulting newbase station combinations to be included in the database. As each suchnew base station combination is added to the database, the RNC alsocalculates its associated DHO node selection result and includes it inthe same database entry. This process should not be allowed to interferewith high-priority tasks, but may be given higher priority than thecontinuous recalculation of DHO node selection results.

When a base station is removed, the RNC may immediately identify andremove all the entries in the database containing base stationcombinations that include the removed base station. It is however notnecessary to do this immediately. Instead the RNC may integrate thisprocess in the continuous recalculation of the database entry. In suchcase the RNC would check the validity of each base station combinationbefore recalculating its associated DHO node selection result. If adatabase entry contains a base station combination that includes aremoved base station, the RNC removes the entry (instead ofrecalculating its DHO node selection result) and moves on to recalculatethe next database entry.

Due to the required updates described above, optimizations are requiredin order to reduce the number of entries in the database. Therefore,embodiments of the present invention also include optimizationsincluding mechanisms for limiting the number of base stationcombinations in the database based on the usefulness of the base stationcombinations. The radio network comprises many base stations whichresults in a great number of theoretically possible combinations of thebase stations. However only a few of these theoretically possiblecombinations will in reality be used. Therefore, the base stationcombinations that are included in the database are those that will beuseful. Embodiments 1 and 2 are examples how the usefulness may bedetermined. The purposes of the optimizations are hence to reduce thememory needed for the database and to reduce the convergence times aftertopology changes (and other changes affecting the DHO node selectioncalculations) for the most frequently used base station combinations. Ingeneral the optimizations reduce the processing and memory requirementsof the invention.

Examples how the number of possible base station combinations, i.e.entries in the database, increases with increasing number of basestations is showed below. Even when limiting the number of base stationsin a base station combination (i.e. in the active set) to three, thenumber of possible base station combinations in a RNS grows drasticallywith growing number of base stations. For example, the applicant'slargest RNC configuration comprises currently 540 base stations, but tobe future proof the non-real-time DHO node selection scheme shouldpreferably anticipate and be able to cope with even largerconfigurations.

The following notation is used in the mathematical expression of thepossible number of base station combinations below:

-   n The number of base stations in the RNS.-   N₂ The number of possible combinations of two base stations.-   N₃ The number of possible combinations of three base stations.-   N_(T) The total number of possible combinations of base stations.

$\begin{matrix}{{{N_{2} = {\begin{pmatrix}n \\2\end{pmatrix} = {\frac{n\left( {n - 1} \right)}{2!} = \frac{n^{2} - n}{2}}}}N_{3} = {\begin{pmatrix}n \\3\end{pmatrix} = {\frac{{n\left( {n - 1} \right)}\left( {n - 2} \right)}{3!} = \frac{n^{3} - {3n^{2}} + {2n}}{6}}}}N_{T} = {{N_{2} + N_{3}} = {\left. \frac{n^{3} - n}{6}\Rightarrow N_{T} \right. = {{k \times n^{3}} + {O(n)}}}}} & \left\{ {{Eq}.\mspace{11mu} 1} \right\}\end{matrix}$

Table 1 illustrates samples of the above mathematical expressions.

TABLE 1 The number of possible combinations of two (N₂), three (N₃) andtwo or three (N_(T)) base stations as a function of the number of basestations (n) in the RNS. n N₂ N₃ N_(T) 10 45 120 165 25 300 2300 2600 501225 19600 20825 100 4950 161700 166650 250 31125 2573000 2604125 500124750 20708500 20833250 1000 499500  1.66167 × 10⁸ 1.666665 × 10⁸ 15001124250 5.613755 × 10⁸ 5.6249975 × 10⁸  2000 1999000 1.331334 × 10⁹1.333333 × 10⁹

FIG. 5 is a diagram showing the number of possible combinations of twobase stations (N₂) as a function of the number of base stations (n) inthe RNS and FIG. 6 illustrates the number of possible combinations ofthree base stations (N₃) as a function of the number of base stations(n) in the RNS. Consequently, the DHO node selection database may becomevery large, requiring undesirably large amounts of memory. In addition,the larger database, the longer time is required to update all theentries (see Table 2), which in turn may result in that the convergencetime after changes (topology changes etc.), i.e. the time until the DHOnode selection results in the database reflect the new situation,becomes unacceptably long.

TABLE 2 Database recalculation times, using plain, unoptimized, cyclicrecalculation, for different numbers of base stations in the RNS andthree different recalculation rates. Apparently the recalculation timesbecome quite unreasonable already for a couple of hundred base stations.Number of Number of Database recalculation times for differentrecalculation rates base database entries, Recalculation rate:Recalculation rate: Recalculation rate: stations, n N_(T) 1 entry/second3 entries/second 10 entries/second 10 165 165 seconds 55 seconds 16.5seconds 25 2600 43.3 minutes 14.4 minutes 4.3 minutes 50 20825 5 hours,47 min 1 hour, 56 min 34.7 minutes 100 166650 46 hours, 18 min 15 hours,26 min 4 hours, 38 min 250 2604125 30 days 10 days 3 days 500 20833250 8months 80 days 24 days 1000 1.666665 × 10⁸ 5.3 years 1 year, 9 months6.3 months 1500 5.6249975 × 10⁸  17.8 years 5.9 years 1 year, 9 months2000 1.333333 × 10⁹ 42.3 years 14.1 years 4.2 years

However, the vast majority of the base station combinations that can beformed are completely unrealistic, due to large geographic separation ofthe base stations, and will in practice never be used. This effect isgreater the more base stations that are connected to the RNC, becausethe number of possible base station combinations increases drasticallywhen the number of base stations increase (see Table 1), whereas thenumber of realistic base station combinations increase at a much lowerrate. Thus it is desired to exclude unrealistic and irrelevant basestation combinations from the database.

In the mathematical expressions used in the estimation of the number ofrealistic base station combinations, the following notation is used, inaddition to the definitions above:

-   C The number of base stations with which a certain (typical average)    base station can form two-leg macro diversity configurations.-   M₂ The number of realistic two-leg macro diversity configurations    (i.e. combinations of two base stations) that include a certain base    station.-   M₃ The number of realistic three-leg macro diversity configurations    (i.e. combinations of three base stations) that include a certain    base station.-   N_(R-tot) The total number of realistic base station combinations    (i.e. macro diversity configurations) in a RNS.-   α A parameter related to the overlap of two neighboring base    stations' respective group of neighbors.-   δ A parameter related to the effects of RNS borders on the number of    intra-RNS base station neighbor relations.-   λ A summarizing parameter,

$\lambda = {\frac{M_{2}}{2} + {\frac{M_{3}}{3}.}}$

To estimate the number of realistic base station combinations in a RNS asimplified model with homogeneously distributed uniform base stationswith negligible impacts from neighboring RNSs is considered. In thismodel, disregarding RNS border effects, a certain base station, denotedBTS A, can only take part in two-leg macro diversity configurations(i.e. macro diversity configurations including two base stations)together with a fixed number, C, of other base stations that aregeographically close enough. These geographically close base stationsare denoted A-neighbors. Thus, the number of possible two-leg macrodiversity configurations, M₂, for a certain base station can beexpressed asM₂=C

The value of C depends on the density of the base stations, theirtransmission power, usage of umbrella cells, algorithms and operatorpolicies used for radio network planning and cell neighbor listconfiguration, etc. In this context the geographical closeness isformalized into the cell neighbor list that is configured for each celland stored in the RNC. A condition for adding a new cell to an activeset, i.e. a soft handover configuration, is that one of the cells thatare already a part of the active set has a formal neighbor relation tothe new cell, i.e. that the new cell is included in the cell neighborlist of at least one of the cells in the active set. This is furtherdescribed below.

For three-leg macro diversity configurations the situation is morecomplicated. The number of three-leg macro diversity configurations, M₃,a certain base station, BTS A, can take part in (again disregarding RNSborder effects) can be expressed as

$M_{3} = {{{\alpha_{1}\frac{C^{2} - C}{2}} + {\alpha_{2}C^{2}}} = {{\left( {\frac{\alpha_{1}}{2} + \alpha_{2}} \right)C^{2}} - {\frac{\alpha_{1}}{2}C}}}$

In this expression the first term, α₁(C²−C)/2, represents the three-legmacro diversity configurations that in addition to BTS A itself includeonly A-neighbors (i.e. base stations from the group of base stationsthat are geographically close enough to the certain base station to formtwo-leg macro diversity configurations with it). The second term, α₂C²,represents the three-leg macro diversity configurations that include onebase station that is not an A-neighbor (i.e. base station combinationsconsisting of BTS A, one A-neighbor and one non-A-neighbor).

Setting α₁=1 makes the first term in the expression for M₃ equal to(C²−C)/2, which is the number of possible base station combinationsincluding BTS A and two A-neighbors. However, some of these base stationcombinations are not realistic, because a terminal will not be able tocommunicate with all three base stations simultaneously, due to thegeographic separation of the base stations. For instance, a combinationof BTS A, the most distant A-neighbor in one direction and the mostdistant A-neighbor in the opposite direction is unrealistic, because aterminal would not be able to communicate with the two A-neighborssimultaneously. To capture this effect α₁ should have a value in therange 0<α₁<1. It is difficult to estimate the value of α₁, but a rough,but probably quite reasonable, estimation yieldsα₁≈¾.

The parameter α₂ has a similar purpose in the second term in theexpression for M₃. But in the case of α₂ the purpose is to capture boththe effect of limited communication range (as in the case of α₁ in thefirst term) and the fact that only a fraction of an A-neighbor'sneighbors (neighbor in this context defined as a base station with whicha two-leg macro diversity configuration can be formed) consists ofnon-A-neighbors. A rough estimation of a reasonable average value of α₂for the whole group of C A-neighbors yieldsα₂≈¼.Using these values of α₁ and α₂ in the above expression for M₃ resultsin the following new expression for M₃:

${M_{3} \approx {{\frac{5}{8}C^{2}} - {\frac{3}{8}C}}} = \frac{{5\; C^{2}} - {3C}}{8}$

The total number of possible macro diversity configurations, M_(T), fora certain base station can hence be expressed as

$\begin{matrix}{M_{T} = {M_{2} + M_{3}}} \\{= {C + {\left( {\frac{\alpha_{1}}{2} + \alpha_{2}} \right)C^{2}} - {\frac{\alpha_{1}}{2}C}}} \\{\approx {C + {\frac{5}{8}C^{2}} - {\frac{3}{8}C}}} \\{= {\frac{5}{8}\left( {C^{2} + C} \right)}}\end{matrix}$

The values of C, α₁ and α₂ are not very important. The point is thatM_(T) is a constant that is independent of the number of base stations,n, in the RNS.

The total number of realistic base station combinations in a RNS,N_(R-tot), is, however, of course not independent of n. N_(R-tot) can beexpressed as

$\begin{matrix}{{N_{R - {tot}} = {{n\left( {\frac{M_{2}}{2} + \frac{M_{3}}{3}} \right)} - {\delta\sqrt{n}}}}\mspace{11mu}\;{\left. {{{where}\mspace{14mu}\delta} < {\sqrt{n}{\left( {\frac{M_{2}}{2} + \frac{M_{3}}{3}} \right).}}}\Rightarrow N_{R - {tot}} \right. = {{\lambda \times n} + {O\left( n^{1/2} \right)}}}\mspace{14mu}{{{where}\mspace{14mu}\lambda} = {\left. {\frac{M_{2}}{2} + {\frac{M_{3}}{3}\mspace{14mu}{is}\mspace{14mu} a\mspace{14mu}{{constant}.}}}\Rightarrow N_{R - {tot}} \right. = {{k \times n} + {O\left( n^{1/2} \right)}}}}} & \left\{ {{Eq}.\mspace{14mu} 2} \right\}\end{matrix}$M₂ is divided by 2 and M₃ is divided by 3 in order to account for thefact that otherwise the number of combinations of two base stationswould be counted twice and the number of combinations of three basestations would be counted thrice. δ√{square root over (n)}, where δ is aconstant, represents the RNS border effects, reflecting the fact thatbase stations close to the border of the RNS have fewer intra-RNSneighbor base stations and hence fewer possible intra-RNS macrodiversity configurations than other base stations. A rough estimation ofδ for a large RNS yields the following expression:

$\begin{matrix}{\delta \approx {0.36 \times \left( {\frac{M_{2}}{2} + \frac{M_{3}}{3}} \right)\sqrt{C\;\pi}}} \\{\approx \left\{ {{\alpha_{1} \approx \frac{3}{4}},\left. {\alpha_{2} \approx \frac{1}{4}}\Rightarrow{{\frac{M_{2}}{2} + \frac{M_{3}}{3}} \approx \frac{{5C^{2}} + {9C}}{24}} \right.} \right\} \approx} \\{\approx {\frac{0.36 \times \sqrt{\pi}}{24}\left( {{5C^{\frac{5}{2}}} + {9C^{\frac{3}{2}}}} \right)}} \\{= {0.015 \times \sqrt{\pi}\left( {{5C^{\frac{5}{2}}} + {9C^{\frac{3}{2}}}} \right)}}\end{matrix}$

The above expression for δ is based on the assumption that the RNSborder effects are, as the term implies, limited to an area at theborders of the RNS, while a major part of the RNS is still more or lessunaffected. This assumption is not true for small RNSs, e.g. n<100.Therefore the expression for δ, and thus the expression for N_(R-tot),does not produce good results when n<100.

As can be seen from {Eq. 1} and {Eq. 2} the number of possible basestation combinations, N_(T), in a large RNS (i.e. with a large n) isapproximately proportional to n³, whereas the number of realistic basestation combinations, N_(R-tot), is approximately proportional to n(where n is the number of base stations in the RNS). This reflects thefact that each base station can only be part of base stationcombinations including neighbor base stations that are locatedreasonably close to it. In practice the fraction of the possible basestation combinations that will ever be used is actually very small. Forlarge RNC configurations it may even be less than 0.1%. This clearlyindicates the potential for reduction of the size of the database.

Table 3 and FIGS. 7 and 8 provide an example to illustrate thedifference between the number of realistic base station combinations andthe number of possible base station combinations. In this example thevalue of C has been set to C=16, which yields M₂=16, M₃≈154 andδ≈151.44.

TABLE 3 The difference between the number of realistic base stationcombinations and the number of possible base station combinations as afunction of the number of base stations in the RNS is illustrated. Thevalue of C is set to C = 16. Due to the poor accuracy in the N_(R-tot)estimation calculations for small values of n, the smallest n value ischosen to n = 100. n N_(R-tot) N_(T) N_(R-tot)/N_(T) 100 4419 1666500.026516 250 12439 2604125 0.004777 500 26280 20833250 0.001261 100054544 1.666665 × 10⁸ 3.27 × 10⁻⁴ 1500 83135 5.6249975 × 10⁸  1.48 × 10⁻⁴2000 111894 1.333333 × 10⁹ 8.39 × 10⁻⁵

FIG. 7 illustrates the number of realistic combinations of two or threebase stations (N_(R-tot)) as a function of the number of base stations(n) in the RNS. FIG. 8 illustrates the number of possible (N_(T)) andthe number of realistic (N_(R-tot)) combinations of two or three basestations as a function of the number of base stations (n) in the RNS.Including the two curves in the same diagram clearly illustrates thesignificant difference. The curve representing the number of possiblecombinations grows very steeply, whereas the curve representing thenumber of realistic combinations remains at reasonable numbers close tothe X-axis even for great numbers of base stations.

Looking at Table 3 the size of a DHO node selection database is notdiscouraging even for a large RNS. As an example, an RNS with 1000 basestations, which is almost twice as many as in the applicant's largestRNC configuration today (which is 540 base stations), the number ofentries in the DHO node selection database would be around 54500,provided that only realistic base station combinations are included inthe database. A reasonable average size of a database entry may bearound 200 bytes if IPv6 addresses are used and around 50 bytes if IPv4addresses are used. Hence, the memory needed for the DHO node selectiondatabase in an RNC controlling 1000 base stations would only be around11 MB in an IPv6 RNS and around 2.6 MB in an IPv4 RNS. For a RNS with100 base stations, the corresponding numbers would be as small as ˜880kB and ˜220 kB respectively.

With small DHO node databases the recalculation times can also be keptwithin reasonable limits, even if rather small computation resources areallocated to the database recalculation. Even when assuming a ratherconservative recalculation rate, e.g. one database entry per second, theentire database in a large RNS of 1500 base stations can be recalculatedwithin 24 hours, which may be quite adequate for an optimizing featurelike selection of distributed DHO nodes, which is not critical for theoperation of the network and which is based on semi-static data.

Table 4 shows the relation between the size of the RNS and the timerequired to recalculate the entire DHO node selection database. However,the average convergence time after a change affecting the DHO nodeselection database is smaller than the time required to recalculate theentire database, since normally only a small fraction of the databaseentries are affected by the change.

TABLE 4 This table provides examples illustrating the relation betweenthe RNS size and the time required to recalculate the entire DHO nodeselection database for three different recalculation rates, assumingthat only realistic base station combinations are included in thedatabase. Number Number of Database recalculation times for differentrecalculation rates of base database Recalculation rate: Recalculationrate: 3 Recalculation rate: stations, n entries, N_(R-tot) 1entry/second entries/second 10 entries/second 100 4419 1 hour, 14 min 25minutes 7.4 minutes 250 12439 3 hours, 27 min 1 hour, 9 min 20.7 minutes500 26280 7 hours, 18 min 2 hours, 26 min 43.8 minutes 1000 54544 15hours, 9 min 5 hours, 3 min 1 hour, 31 min 1500 83135 23 hours, 6 min 7hours, 42 min 2 hours, 19 min 2000 111894 31 hours, 5 min 10 hours, 22min 3 hours, 6 min

The above discussion shows that a DHO node selection database can berestricted to a rather easily manageable size even for a large RNS.Moreover, even when considering only the realistic base stationcombinations, not all combinations will be equally frequently used. Somecombinations are more likely, and some are quite unlikely, to appear inmacro diversity configurations.

Another circumstance to keep in mind is that the information in the DHOnode selection database has a semi-static nature. Changes that affectthe DHO node selection database happen quite rarely. These circumstancescan be utilized to design schemes that reduce the size of the databaseand/or optimize the recalculation of the database. Thereby the requiredmemory can be reduced and the convergence time after changes that affectthe DHO node selection database (e.g. topology changes, link upgradesaffecting the generic cost metric of the link, base station upgradesfrom non-DHO capable to DHO capable, etc.) can be greatly improved forthe realistic base station combinations, especially for those mostfrequently used.

Excluding unrealistic and irrelevant base station combinations from thedatabase is an optimization that obviously saves memory. As a by-productit also reduces the time required to recalculate the database and thusreduces the convergence time. Another way to reduce the convergence time(except allocating more processing resources to the databaserecalculation) is to improve the recalculation method, e.g. by moreintelligently selecting the database entries to be recalculated thansimply going through all the database entries in a repetitive cycle.Through smart optimizations the resources consumed by the non-real-timeDHO node selection scheme, in terms of memory and processing, can bereduced to rather insignificant numbers. According to one embodiment,the number of base station combinations in the database is limited basedon the usefulness of the base station combinations.

Embodiment 1

The aim of the first embodiment is to reduce the size of the database.In this embodiment, the determination of the usefulness of a basestation combination is based on neighbor relations of the base stationswithin the base station combination. Thus, the inclusion of base stationcombinations is performed selectively based on the cell neighbor listsin order to reduce the size of the database. That implies that basestation combinations for which the base stations can be linked togethervia base station neighbor relations are included in the database.

As mentioned above, the geographical closeness that is needed for twocells to be part of the same soft handover configuration, i.e. to bepart of the active set, is formalized in the configured cell neighborlists. That is, each cell has a cell neighbor list associated with it,which specifies the cells in its vicinity (including both cellsbelonging to the same site, i.e. the same base station, and cellsbelonging to neighboring base stations) that are considered to be itsneighbors in a soft handover context. You could see a neighbor relationdefined in a cell neighbor list as a logical unidirectional “cellneighbor link” between the cell and the neighbor cell. A new cell can beadded to the active set, i.e. added to the cells taking part in a softhandover configuration, only if there is a cell neighbor link to the newcell from one of the cells that are already a part of the active set. Asa consequence, all the cells in a soft handover configuration can alwaysbe linked together in an unbroken chain of cell neighbor links. No cellcan be isolated (in terms of cell neighbor links) from the others andneither can there, in a soft handover configuration, be groups of cellsthat are isolated from each other (in terms of cell neighbor links).

Zooming out from the cell perspective to a site (base station)perspective the term “base station neighbor link” can be defined. A basestation neighbor link is different from a cell neighbor link, becauseeach base station may serve up to three cells in each frequency band(but in UTRAN a soft handover configuration can only use cells from thesame frequency band). For the purpose of simplifying explanations inthis document a base station neighbor link between base station 1 andbase station 2 is defined as existing if at least one of the cellsbelonging to base station 1 has a cell neighbor link to at least one ofthe cells belonging to base station 2 (or with other words that at leastone of the cells belonging to base station 2 is included in the cellneighbor list of at least one of the cells belonging to base station 1)or at least one of the cells belonging to base station 2 has a cellneighbor link to at least one of the cells belonging to base station 1.

The cell neighbor lists in the RNC, and the base station neighbor linksthat can be derived from them, can be used to determine which basestation combinations that are realistic. In this embodiment onlycombinations for which the base stations can be linked together via basestation neighbor links (i.e. via cell neighbor relations) are includedin the DHO node selection database.

Base station neighbor links have, however, a somewhat dynamic nature,since cells and base stations may be added and removed in the radionetwork and cell neighbor lists may be changed. Hence, determining thebase station combinations to be included in the DHO node selectiondatabase is not a one-time event. On the contrary, there must bemechanisms that ensure that the contents of the DHO node selectiondatabase always reflect the current configuration of the radio network.

One way to cope with the dynamic nature of the radio networkconfiguration is to trigger a “re-evaluation procedure” every time a newcell or a new base station is added or removed or a cell neighbor listis changed. The re-evaluation procedure would, starting from scratch,identify, based on base station neighbor links derived from the cellneighbor lists, the base station combinations to be included in the DHOnode selection database. It would delete the ones that no longer belongin the database, if any, and include possible new ones.

A smarter and more efficient re-evaluation procedure could use the new,removed or changed neighbor list(s) as its basis and use thisinformation to identify the existing realistic base station combinations(i.e. base station combinations that are included in the database) thatare potentially affected and the new ones that can be formed, instead ofstarting the procedure from scratch.

Alternatively, instead of being triggered by radio networkreconfiguration events a re-evaluation procedure may be continuouslyrunning in the background, constantly modifying (when mismatches arefound) the set of base station combinations in the DHO node selectiondatabase.

Embodiment 2

The aim of the second embodiment is to reduce the size of the databasesimilar to the first embodiment. According to the second embodiment, thedetermination of the usefulness of a base station combination is basedon previous actual use of the base station combination.

In this embodiment the DHO node selection database is empty when thesystem is taken into use, to be gradually filled with entries based onactual usage data. Thus, a base station combination is not included inthe database, until it is used in a macro diversity configuration, i.e.when it has proven its usefulness.

The first time a base station combination is used it is included in thedatabase and its corresponding DHO node selection result is calculated.However, since this is a non-real-time DHO node selection mechanism,whose purpose is to relax the real-time requirements on the DHO nodeselection algorithm, the DHO node selection result is not calculatedfast enough to satisfy the real-time requirements of connectionestablishment and macro diversity configuration changes. Hence, the DHOfunctionality is handled in the traditional way, i.e. only in the RNC,the first time a certain base station combination is used. (It would ofcourse be possible to execute the DHO node selection algorithm inreal-time the first time a certain base station combination is used, butthis is not recommended.)

Subsequently, the next time the same base station combination is used ina macro diversity configuration, the DHO node selection result can beretrieved from the database.

This mechanism also requires that the usage of the existing databaseentries are monitored, so that entries that are no longer useful can bedeleted. After e.g. topology changes or changes in the cell neighborlists, a certain base station combination may become totally unrealistic(or even impossible e.g. if one of the included base stations has beenremoved). To remove such useless entries from the database the RNC maymaintain a timestamp in each entry, e.g. denoted T_(last-usage),indicating the last time the database entry was used. If the time sincea certain entry was used exceeds a certain threshold, e.g. denotedT_(threshold) (i.e. if T_(current)−T_(last-usage)>T_(threshold)), thenthe RNC deletes the entry from the database. This “pruning procedure”may be integrated with the recalculation of the database, such that thecondition T_(current)−T_(last-usage)≦T_(threshold) (where T_(current)denotes the current time) is checked prior to recalculating eachdatabase entry.

The timing out of unused database entries may also be based on thefrequency with which each entry is used. A suitable measure of thisusage frequency could be an exponential average of the time periodbetween two consecutive times that an entry is used. If this exponentialaverage exceeds a certain threshold value, the entry is deleted. Inconjunction with embodiment 3, it is described how such an exponentialaverage can be calculated.

Embodiment 3

Embodiments 3-6 provide optimizations of the recalculation of thedatabase entries, aiming to improve convergence times and reduce theprocessing requirements.

A way to improve the average convergence time after changes that affectthe DHO node selection database is to optimize the recalculation of thedatabase entries such that more frequently used entries are recalculatedmore often than others by using a non-Uniform Use-Based DatabaseRecalculation scheme according to embodiment 3. To achieve this the RNCshould keep track of how often the entries are used, i.e. how often thecorresponding base station combinations are used in macro diversityconfigurations.

Every time a certain base station combination is used in a macrodiversity configuration the RNC records the current time in a timestamp,T_(last-usage) (indicating the last time the entry was used), in thedatabase entry for that combination. This T_(last-usage) timestamp maybe the same as the one described in conjunction with embodiment 2.

An exponential average of the time period between two consecutiveoccasions when the entry is used, P_(A), is also calculated and storedin the database entry. That is the RNC calculatesP_(A-new)=φ×P_(A-old)+(1−φ)×(T_(current)−T_(last-usage)) and storesP_(A-new) as the new usage period average and T_(current) (the currenttime) as the new timestamp (i.e. as the new T_(last-usage)) In thisexponential average formula P_(A-old) and T_(last-usage) are the P_(A)value and the timestamp that were previously stored in the databaseentry. φ is a constant that satisfies 0<φ<1 and which governs how fastthe influence of old values on the exponential average decreases. Theextreme (trivial) cases φ=0 and φ=1 are of little interest. For φ=1P_(A) becomes a constant, which means that a recalculation scheme thatdepends on P_(A) will not have the desired non-uniform properties. Forφ=0 P_(A) will always be equal to the time period between the two lasttimes the concerned Node B combination was used. P_(A), and consequentlya depending recalculation scheme, would then potentially vary quitewidely. Over time the recalculation scheme could still have reasonableproperties, but a more smoothly varying P_(A) is likely to give thedepending recalculation scheme more desirable properties. However, oneadvantage of setting φ=0 is that it simplifies the calculations and maystill give the non-uniform recalculation scheme at least acceptableproperties. A suggested value of φ is φ=0.8.

The RNC should also ensure that the value of P_(A) does not become toolarge for an entry, because that could result in an unnecessarily andunacceptably long convergence time for that entry, if a change thataffects the entry occurs. Therefore, if the calculation of P_(A-new)results in a value exceeding a maximum allowed value, P_(A-max), thenthe RNC should set P_(A-new)=P_(A-max).

That is, the complete calculations that the RNC performs every time adatabase entry is used are:P _(A-new) =φ×P _(A-old)+(1−φ)×(T _(current) −T _(last-usage))IF P_(A-new)>P_(A-max) THEN P_(A-new)=P_(A-max)T_(last-usage)=T_(current)P_(A-new) and T_(last-usage) are then stored in the database entry.P_(A) should preferably be initiated to a rather high value, e.g.P_(A-init)=P_(A-max)/2. T_(last-usage) is initiated to the time when thedatabase entry was created (or the time when the RNC is taken intoservice).

Furthermore, every time the RNC recalculates the DHO node selection of adatabase entry it should record the current time in a second timestamp,T_(last-recalculation), in the recalculated entry.T_(last-recalculation) is initiated to the time when the database entrywas created (or the time when the RNC is taken into service).

As the RNC repeatedly goes through the database to recalculate itsentries, it recalculates the DHO node selection only for those entriesfor which the condition T_(current)−T_(last-recalculation)>K×P_(A)(where T_(current) is the current time) is fulfilled. K is a configuredconstant that probably should be rather large, e.g. K>>1. What areasonable value for K is depends on what typical values of P_(A) thatcan be expected, how often changes that affect the DHO node selectioncan be expected to occur and, to a certain extent, how much of the RNC'scomputation resources an operator is willing to use for DHO nodeselection database recalculation. Lacking such statistics a ratherarbitrary suggestion would be to choose K within the range 5≦K≦50. Thevalue of K could be fine-tuned based on statistics. A too small value ofK could result in that too many of the database entries are recalculatedevery time the RNC goes through the database, thus resulting in lessthan intended differentiation of the recalculation frequencies fordifferent entries. On the other hand, a too large value of K couldresult in that the RNC repeatedly goes through the entire databasewithout recalculating a single entry, which could be seen as a waste ofcomputation resources.

With this scheme the usage frequency of a database entry governs howoften the entry is recalculated, thereby focusing the recalculationresources where they are needed the most.

In a variation of the non-uniform recalculation scheme the condition forrecalculating an entry is replaced by a more rudimentary classificationof the entries into three classes, based on their respective currentP_(A) value. The three classes are:

-   class 1: P_(A)≦P_(A-class-1-max)-   class 2: P_(A-class-1-max)<P_(A)≦P_(A-class-2-max)-   class 3: P_(A)>P_(A-class-2-max)

The RNC then recalculates the database entries based on these classes asfollows (“Recalculation round” refers to the process of once goingthrough all the entries in the database, checking the recalculationcondition for each entry and recalculating the entries for which thecondition is fulfilled):

First recalculation round: recalculate class 1 and class 2 entriesSecond recalculation round: recalculate class 1 and class 3 entriesThird recalculation round: recalculate class 1 and class 2 entriesRepeat the three rounds in a repetitive cycle.or:

First recalculation round: recalculate all entries Second recalculationround: recalculate class 1 and class 2 entries Third recalculationround: recalculate class 1 entriesRepeat the three rounds in a repetitive cycle.

With this variation using a condition for recalculation based on classesthe RNC does not have to store the T_(last-recalculation) timestamp inthe database entries.

Variations with two, four or more entry classes are also conceivable.

If the dynamic use-based selective inclusion of base stationcombinations according to the second embodiment is used, P_(A) may alsobe used to monitor the usage frequency database entries for the purposeof timing out unused or very rarely used entries. If P_(A) exceeds athreshold value denoted P_(A-timeout) (i.e. if P_(A)>P_(A-timeout)),then the entry is deleted from the database.

P_(A-timeout) should be set to a large value, e.g.P_(A-timeout)=100×P_(A-max). If P_(A) is used in this way as a basis fortiming out useless database entries and if P_(A-timeout)≧P_(A-max), thenthe timeout mechanism will not work, if P_(A), as described above, isnot allowed to exceed P_(A-max). Therefore, in case P_(A) is used in thetimeout mechanism, the actual P_(A) value must be maintained and insteadthe smallest of P_(A) and P_(A-max) should be used when checking therecalculation condition. That is, the calculations that the RNC performsevery time a database entry is used become:P _(A-new) =φ×P _(A-old)+(1−φ)×(T _(current) −T _(last-usage))T_(last-usage)=T_(current)P_(A-new) and T_(last-usage) are then stored in the database entry.

And the condition for recalculating a database entry becomes:T _(current) −T _(last-recalculation)>K×MIN(P _(A) ,P _(A-max))

Embodiment 4

One way to save time during the database recalculation process is tointerrupt the recalculation of en entry, if it can be determined thatthe recalculation is redundant and that the result of the recalculationwill not change the contents of the entry.

If the route tree for a certain base station combination (i.e. the treeof routes formed by the route from the RNC to each of the involved basestations) is the same, including both topology and link metrics, as thelast time the entry was calculated, there is no need to perform therecalculation (since the result will inevitably be the same as the onethat is already stored in the entry). But how does the RNC detect thatthe route tree is unchanged?

One way is to store the entire route tree in the DHO node selectiondatabase entry and compare it with the new one derived from freshinformation from the topology database before performing the rest of thecalculation.

Another way is to store a “signature” or a “digest” of the route tree(instead of the entire route tree) in the DHO node selection databaseentry, e.g. in the shape of a hash or a CRC calculation. This requiresless memory than storing the entire route tree. However, a weakness ofthis method is that there is a (small but non-zero) risk that the digestof an updated route tree becomes the same as the digest of the routetree before the update, even though the two route trees are not equal.In such case the corresponding entry in the DHO node selection databasewould incorrectly be left unchanged, until the route tree of theconcerned base station combination is once again updated.

A third way is to associate and store a timestamp with each route in thetopology database. The timestamp would indicate the last time the routewas updated. The RNC could use these timestamps in two different ways.It could compare them with a recalculation timestamp in the DHO nodeselection database entry, e.g. the same recalculation timestamp that wasdescribed in conjunction with the non-uniform use-based databaserecalculation scheme of the third embodiment, denotedT_(last-recalculation) indicating the last time the entry wasrecalculated. If, when recalculation of an entry is considered, none ofthe timestamps of the concerned routes in the topology databaseindicates a time that is later than the recalculation timestamp in theDHO node selection database, then the recalculation need not beperformed. Hence the condition for concluding the recalculation of a DHOnode selection database entry becomes thatT_(route)>T_(last-recalculation) (where T_(route) denotes the timestampassociated with a route in the topology database) is true for at leastone of the concerned routes.

There is however a small risk that a route is updated after the routehas been retrieved from the topology database, but before theT_(last-recalculation) timestamp is written in the DHO node selectiondatabase entry. If this happens, the timestamp of the route, T_(route),will indicate an earlier time than T_(last-recalculation) which meansthat the next time (and following times) recalculation is considered forthe concerned DHO node selection database entry, the entry willincorrectly be left unchanged (unless one of the concerned routes hasbeen further updated in the meantime). To avoid this risk the timestampcondition could include a safety margin, such that the condition forconcluding the recalculation of an entry becomes thatT_(route)>T_(last-recalculation)−S (where S is a time period thatexceeds the maximum possible/reasonable time between retrieval of aroute from the topology database and recording of theT_(last-recalculation) timestamp in the DHO node selection databaseentry) is true for at least one of the concerned routes.

The other way to use the timestamps in the topology database is to storein each entry in the DHO node selection database the timestamps of allroutes that were used in the calculation of the entry. If all thesetimestamps are the same when recalculation of the entry is considered,the recalculation need not be performed. In this case the timestampscould also be replaced by sequence numbers (incremented every time aroute is updated) or a digest associated with each route in the topologydatabase.

If recalculation timestamps are used in the DHO node selection database,for whatever purpose, they should be updated even when the recalculationof the entry is interrupted.

The topology database timestamps referred to in this section, T_(route)may be the same as the ones described in conjunction with embodiment 8described below (denoted T_(last-relevant-event)) and just as thosetimestamps they may also be stored in a list that is separate from thetopology database.

Embodiment 5

A more or less ideal way to maintain the DHO node selection database isto trigger updates of each base station combination (i.e. databaseentry) only when needed, i.e. only when a change of the networkconfiguration has occurred that affects the result of the DHO nodeselection calculation of that base station combination. A way to comeclose to this ideal is to have a tighter coupling between themaintenance of the topology database and the maintenance of the DHO nodeselection database, such that changes in the topology database triggersupdating of potentially affected entries (also referred to as basestation combinations) in the DHO node selection database.

When a change occurs in the topology database that potentially affectsthe DHO node selection calculations in the DHO node selection database,the RNC identifies and recalculates the entries in the DHO nodeselection database that include the concerned base stations. Suchchanges include:

-   -   Changes in the route to a base station (including both changes        in the path and changes in the link metrics).    -   Changes in the DHO capability status of a node in the route to a        base station or in the base station itself.

Other changes that affect the DHO node selection database include:

-   -   Removal of a base station from the RNS.    -   Deployment of a new base station in the RNS.    -   Changes in the cell neighbor lists. (That is however only        relevant if the inclusion of base station combinations in the        DHO node selection database is based on neighbor relations.)

These other changes do not require recalculations of existing DHO nodeselection database entries. Instead they trigger deletion of old and/orcreation of new entries in the DHO node selection database.

This “reactive” recalculation of DHO node selection database entries isclose to the ideal in the sense that updates are triggered by actualchanges and the entries to be updated are selected based on actualchanges in the topology database. If nothing is changed in the topologydatabase, no resources are wasted on redundant recalculations in the DHOnode selection database. However, the method will still cause redundantrecalculations, because the selection of affected entries is notperfect. Even if an entry in the DHO node selection database includes abase station, whose route has been updated in the topology database, therecalculation of the DHO node selection result in the entry may stillarrive at the same (i.e. unchanged) result.

A limitation of this reactive recalculation method is, however, that itonly works together with DHO node selection algorithms that consideronly potential DHO nodes that are part of the route tree formed by theroutes to the involved base stations, i.e. so called “on-tree” DHO nodes(see WO2005/62654). Otherwise it will not be possible to identify theaffected entries in the DHO node selection database without performingthe actual DHO node selection calculation for each entry.

Another limitation is that the reactive recalculation method may not bevery efficient, if the delay metrics in the topology database are basedon continuously repeated delay measurements (e.g. using the traceroutemechanism described in WO2005/62654), which cause small, but frequent,changes in the topology database. To reduce the number and frequency ofinsignificant measurement-based delay metric changes in the topologydatabase the delay metrics could have a rather coarse granularity andcould be based on rather extensive smoothing (e.g. using exponentialaveraging) of the measurement values. Without such countermeasures thesechanges may trigger frequent recalculations, which to the most part willbe redundant, because the triggering delay metric change is too small tohave an impact on the final DHO node selection calculation result.However, this property of the delay metric changes can be utilized toevade most of the impact of this limitation.

Given that the change that has triggered recalculations is a link delaymetric change in the topology database it is possible to immediatelysort out those of the affected entries in the DHO node selectiondatabase, whose DHO node selection result obviously will not be affectedby the change, by including a “delay metric sensitivity threshold” inthe database entry. The delay metric sensitivity threshold is calculatedduring the DHO node selection calculation and indicates the least changein link delay metrics (positive or negative) that may affect the outcomeof the DHO node selection calculation. More advanced schemes, e.g. withdifferent delay metric sensitivity thresholds for different routes orspecific links, are also conceivable. However, such advanced schemesrequire more analysis, calculation and storage, which are obviousdisadvantages. The scheme presented herein is seen as a reasonablecompromise.

For example, when the DHO node selection algorithms described inWO2005162654 are used, the delay metric sensitivity threshold mayindicate the smallest delay metric change that would impact thecomparison between the transport delay of the macro diversity legs andthe maximum allowed transport delay between a base station and the RNC.This impact could be in both directions. If the delay metric isincreased, it may cause the transport delay of one of the macrodiversity legs in the selected DHO node tree to exceed the maximumallowed transport delay. If the delay metric is decreased, it may causethe transport delay of a macro diversity leg in a discarded (because oftoo large transport delay) DHO node tree to go below the maximum allowedtransport delay.

Thus, when a link delay metric is changed in the topology database, theRNC should note the size of the change and use it when identifying theaffected entries in the DHO node selection database. With this mechanismthe condition for recalculating an entry due to changes in the topologydatabase, i.e. that the route to one of the base stations in the entryhas been updated, is complemented with the condition that if thetriggering change is a delay metric change, the entry is recalculatedonly if the size of the change is greater than the delay metricsensitivity threshold stored in the entry. With this additionalcondition most of the small, insignificant delay metric changes will notcause any recalculations in the DHO node selection database.

However, even if a delay metric change is too small to triggerrecalculation of an affected entry, it may impact the delay metricsensitivity threshold of the entry. Therefore the delay metricsensitivity threshold of the affected entry has to be recalculated. Thismay however prove counterproductive, because the only way to do thisproperly is to redo the entire DHO node selection calculation, theavoidance of which is the very purpose of the delay metric sensitivitythreshold. Therefore a simplified method is used. Assuming the worstcase the delay metric sensitivity threshold is simply reduced by thesize of the triggering delay metric change. In most cases this reductionwill be too great. In many cases the real change of the delay metricsensitivity threshold may even have been an increase. A refinement ofthe scheme, that at least ensures that the delay metric sensitivitythreshold is not decreased when it should actually be increased, is tocalculate and store two delay metric sensitivity thresholds in eachentry: one that indicates the smallest delay metric increase and onethat indicates the smallest delay metric decrease that may affect theDHO node selection calculation result. This makes the recalculationcondition more fine-tuned (considering not only the size but also thesign of the delay metric change) as well as ensures that the delaymetric sensitivity thresholds can be adjusted in the right direction.

Depending on how the link delay metrics are measured the link delaymetric changes may be detected one by one or several together in onemeasurement. If for instance the traceroute mechanism described inWO2005/62654 is used to measure the link delays, the link delays of allhops in the path between the RNC and a base station will be measuredduring the same measurement. If the change that triggers possiblerecalculations in the DHO node selection database involves several linkdelay metric updates, then the all the updates affecting any of theroutes to the base stations included in an entry should be taken intoaccount when considering recalculation of the entry. The size of thedelay metric update, D_(update-size), that should be used in therecalculation condition will thus be different for different databaseentries (depending on how many of the link delay metric updates thataffect routes to the base stations that are included in the entry) andshould be calculated as follows:

${D_{{update}\text{-}{size}} = {{MAX}\left( {{\sum\limits_{i = 1}^{k}\; D_{i}^{+}},{\sum\limits_{i = 1}^{l}\;\left| D_{i}^{-} \right|}} \right)}},$where D⁺ indicates a delay increase, D⁻ indicates a delay decrease, k isthe number of delay metric increases affecting the routes to the basestations of the entry and l is the number of delay metric decreases thataffects the routes to the base stations of the concerned entry.

If dual delay metric sensitivity thresholds are used, one for delayincreases and one for delay decreases, then both sums in the abovecalculation (instead of just the greatest one) should be used as thesizes of the delay metric increase and decrease respectively.

It may be useful to complement the reactive recalculation scheme with amechanism that ensures that if the reactive recalculation scheme forsome reason fails to recalculate an entry that should have been updated,e.g. due to programming errors or temporary malfunctioning, then thisentry is not left with an erroneous DHO node selection resultindefinitely. Such a complementing mechanism could be a slowlyrepetitive recalculation scheme running in the background. Therepetitive recalculation scheme could be a non-uniform use-basedrecalculation scheme, as described in conjunction with the thirdembodiment, or a simple cyclic recalculation of all database entries.

Embodiment 6

An efficient way to reduce the convergence times is to temporarilyallocate more computation resources to the database recalculationwhenever a change occurs that can be assumed to have affected the DHOnode selection database. Such changes are exemplified in embodiment 5.This mechanism should preferably be automatic and triggered by allrelevant changes, but it could also be manual and used after certainselected major changes.

It would be beneficial to combine this optimization with reactiverecalculation triggered by changes, as described in conjunction withembodiment 5.

Embodiment 7

Embodiments 7-9 provide optimizations aiming to avoid usage of outdateddatabase entries.

Using a database entry that is affected by a recent change, but has notyet been updated may have undesirable consequences. It may result insuboptimal DHO node selection, which in turn may result in suboptimal(and even unacceptable) performance in terms of transmission delays andusage of transmission resources.

Even though such outdated database entries are present only duringlimited transient periods after the rather non-frequent changes thataffect the DHO node selection database, it may be desirable to providemechanisms to avoid using outdated database entries.

One such mechanism is based on timestamps. The RNC records the time ofthe last event that may potentially affect the DHO node selectiondatabase in a timestamp, e.g. denoted T_(last-relevant-event). Inaddition the RNC maintains a timestamp in each entry in the DHO nodeselection database, indicating the last time the entry was recalculated,e.g. denoted T_(last-recalculation) (e.g. the same recalculationtimestamp that was described in conjunction with the non-uniformuse-based database recalculation scheme according to embodiment 3 and/orthe one described in conjunction with the interrupting redundantrecalculations scheme according to embodiment 4). When looking up DHOnode selection information in the DHO node database, the RNC wouldcompare T_(last-recalculation) of the relevant entry withT_(last-relevant-event) and decide to use the information in the entryonly if T_(last-recalculation)>T_(last-relevant-event). Just as in themechanism for interrupting redundant recalculations described forembodiment 4, a safety margin can be introduced in the condition suchthat the condition for using the information in the entry insteadbecomes that T_(last-recalculation)−S>T_(last-relevant-event).

Embodiment 8

The above described method (embodiment 7) of using timestamps to avoidusing outdated database entries can in accordance with embodiment 8 beenhanced by replacing the overall “event timestamp”, i.e.T_(last-relevant-event) with multiple timestamps, one for each basestation in the RNS. This enhancement will, however, only work togetherwith DHO node selection algorithms that consider only potential DHOnodes that are part of the route tree formed by the routes to theinvolved base stations, i.e. so called “on-tree” DHO nodes (seeWO2005/62654).

In this embodiment the RNC maintains a list of all the base stations inthe RNS, e.g. denoted “base station event list”. Associated with eachbase station in the list is a timestamp indicating when the last eventoccurred that may affect entries in the DHO node selection database thatinclude the base station. Such events may include:

-   -   Changes in the route to a base station (including both changes        in which nodes that are traversed and changes in the link        metrics).    -   Changes in the DHO capability status of a node in the route to a        base station (or in the base station itself).    -   Removal of a base station from the RNS.

Deployment of a new base station in the RNS.

Other changes that may affect the DHO node selection results.

All the above events (except possibly the last “general” event) can, ifyou like, be seen as changes in the topology database (provided that theDHO capability status of each node is stored in the topology database).Thus, the timestamps could also be stored in the topology database, withone timestamp associated with each route (which corresponds to a basestation), instead of in a separate list. The timestamps could be thesame as the ones described in conjunction with the mechanism forinterrupting redundant recalculations in accordance with embodiment 4(denoted T_(route)).

As in the above described timestamp based method, a timestamp indicatingthe last time the entry was recalculated, T_(last-recalculation) (e.g.the same recalculation timestamp as the one described in conjunctionwith embodiment 3 and/or embodiment 4) is stored in each entry in theDHO node selection database. However, in this enhanced method thecondition for using the information in an entry in the DHO nodeselection database is thatT_(last-recalculation)>T_(last-relevant-event) is true for all the basestations that are included in the entry. That is, for each base stationin the base station combination of the concerned database entry theassociated event timestamp, T_(last-relevant-event), has to beretrieved, from the base station event list or from the topologydatabase, and compared with the recalculation timestamp,T_(last-recalculation), of the concerned database entry. Just as in themechanism for interrupting redundant recalculations described inconjunction with embodiment 4, a safety margin can be introduced in thecondition such that the condition instead becomes thatT_(last-recalculation)−S>T_(last-relevant-event) is true for all thebase stations that are included in the entry.

Embodiment 9

Another, brute but efficient, method to avoid usage of outdated databaseentries is to simply temporarily disable the macro diversityfunctionality means, and thus revert to using only RNCs as DHO nodes,after events that affect the content of the database comprising the basestation combinations, until the database has been recalculated. Thismethod may also be used selectively, e.g. only when certain major eventsoccur that can be expected to have a large impact on the DHO nodeselection database.

To reduce the negative impact of this method it should preferably becombined with temporary allocation of additional computation resourcesfor DHO node selection database recalculation, as described inconjunction with embodiment 6.

The nine described embodiments may be divided into three categoriesbased on their aims. The first category comprises the first and secondembodiments wherein the aim of the first and second embodiments is toreduce the size of the database. The second category comprises the thirdto the sixth embodiments wherein embodiments 3-6 provide optimizationsof the recalculation of the database entries, aiming to improveconvergence times and reduce the processing requirements. The thirdcategory comprises the seventh to ninth embodiments wherein embodiments7-9 provide optimizations aiming to avoid usage of outdated databaseentries.

The three categories are independent of each other such that anyoptimization of the first category may be used in combination with anyoptimization of the second and third categories used separately or incombination. It is however preferred to use at least one optimizationfrom each of the two first categories.

Embodiment 2 is the preferred embodiment. It is also preferred to useembodiment 2 in combination with one or two other optimizations definedby embodiments 3-8. Which these other optimizations are, depends on:

Whether the DHO node selection algorithm considers only potential“on-tree” DHO nodes (i.e. potential DHO nodes that are part of the routetree formed by the routes from the RNC to the involved base stations,see WO2005/62654. The expected frequency of changes in the topologydatabase.

The first of these two “input parameters” can be formalized to a binaryvariable with the two possible values “on-tree DHO node selectionalgorithm” (or simply “on-tree algorithm”) and “unconstrained DHO nodeselection algorithm” (or simply “unconstrained algorithm”). “On-treealgorithm” refers to a DHO node selection algorithm that selects DHOnodes only from the nodes that are part of the route tree formed by theroutes from the RNC to the involved base stations. “Unconstrainedalgorithm” refers to a DHO node selection algorithm that is notconstrained to select DHO nodes only from the nodes that are part of theroute tree formed by the routes from the RNC to the involved basestations.

Similarly, the second “input parameter” may be simplified and formalizedto a variable with the three possible values “low change frequency inthe topology database” (or simply “low change frequency”), “mediumchange frequency in the topology database” (or simply “medium changefrequency”) and “high change frequency in the topology database” (orsimply “high change frequency”). “Low change frequency” implies a changefrequency that has no significant impact on the performance of any ofthe embodiments. “Medium change frequency” implies a change frequencythat is rather high, but does not exceed a reasonable recalculation rate(i.e. it is not too high for the recalculation triggered by changesmethod of embodiment 5 to keep up with it). “High change frequency”implies a change frequency that exceeds a reasonable recalculation rate(i.e. it is too high for the recalculation triggered by changes methodof embodiment 5 to keep up with it).

Six different combinations, or cases, can be formed of these twovariables, resulting in potentially different recommendations on whichembodiment(s) to use in combination with the dynamic use-based selectiveinclusion of base station combinations (embodiment 2) in the DHO nodeselection database.

For the two cases “on-tree algorithm” and “low change frequency” or“medium change frequency” it is recommended to use the reactiverecalculation triggered by changes (embodiment 5) and probably also thetimestamp and base station list based method to avoid using outdateddatabase entries (embodiment 8). Optionally, temporary allocation ofadditional computation resources to database recalculation (embodiment6) may also be used.

For the case “on-tree algorithm” and “high change frequency” it isrecommended to use the non-uniform use-based database recalculationoptimization (embodiment 3) and the timestamp and base station listbased method to avoid using outdated database entries (embodiment 8).

For the case “unconstrained algorithm” and “low change frequency” it isrecommended to use the non-uniform use-based database recalculationoptimization (embodiment 3) and possibly the timestamp based method toavoid using outdated database entries (embodiment 6). Optionally,temporary allocation of additional computation resources to databaserecalculation (embodiment 6) may also be used.

For the case “unconstrained algorithm” and “medium change frequency” itis recommended to use the non-uniform use-based database recalculationoptimization (embodiment 3). Optionally, temporary allocation ofadditional computation resources to database recalculation (embodiment6) may also be used.

For the case “unconstrained algorithm” and “high change frequency” it isquestionable whether this non-real-time DHO node selection scheme isuseful at all.

The present invention is not limited to the above-described preferredembodiments. Various alternatives, modifications and equivalents may beused. Therefore, the above embodiments should not be taken as limitingthe scope of the invention, which is defined by the appending claims.

1. An arrangement adapted to be located in a network node in a mobile communication network for selecting at least one diversity handover, DHO, node, that is to perform macro diversity functions, amongst the nodes of the mobile communication network comprising macro diversity functionality means, the selection is based on base station combinations of said mobile communication network and the arrangement comprises: means for retrieving at least one DHO node, that is to perform macro diversity functions, from a database comprising base station combinations of said mobile communication network and a pre-calculated DHO node selection for each such base station combination; means for updating the base station combinations to be included in the database; means for removing base station combinations from the database by time stamping each used base station combination such that the last time the combination was used is indicated; and means for removing a base station combination from the database based on an exponential average of time periods between two consecutive uses of said base station combination indicated by the time stampings.
 2. The arrangement according to claim 1, wherein the nodes comprising macro diversity functionality means being base stations and nodes controlling base stations.
 3. The arrangement according to claim 1, wherein the nodes comprising macro diversity functionality means being base stations.
 4. The arrangement according to claim 1, comprising means for determining the usefulness of a base station combination based on neighbor relations of the base stations within the base station combination.
 5. The arrangement according to claim 1, comprising means for including base station combinations for which the base stations can be linked together via base station neighbor relations in the database.
 6. The arrangement according to claim 4, comprising means for determining the usefulness of a base station combination based on previous actual use of the base station combination.
 7. The arrangement according to claim 1, comprising means for triggering updating of the base station combinations to be included in the database by a configuration change of the mobile communication network.
 8. The arrangement according to claim 1, comprising means for performing continuous updating of the base station combinations to be included in the database as a background process.
 9. The arrangement according to claim 1, comprising means for basing updates of the base station combinations to be included in the database on new base station neighbor relations.
 10. The arrangement according to claim 1, comprising means for removing a base station combination from the database if the time since said base station combination was time stamped exceeds a pre-defined threshold.
 11. The arrangement according to claim 1, comprising means for removing a base station combination from the database based on a frequency with which said base station combination has been used.
 12. The arrangement according to claim 1, comprising means for updating the pre-calculated DHO node selections for the base station combinations stored in the database.
 13. The arrangement according to claim 12, comprising means for performing continuous updating of the pre-calculated DHO node selections for the base station combinations in the database as a background process.
 14. The arrangement according to claim 12, comprising means for triggering updating of the pre-calculated DHO node selections for the base station combinations in the database by a configuration change of the mobile communication network.
 15. The arrangement according to claim 14, comprising means for temporarily allocating more computation resources to the updating when the configuration of the mobile communication network changes.
 16. The arrangement according to claim 12, comprising means for interrupting updating of the pre-calculated DHO node selection of a base station combination in the database if it is determined that the updating will not change the DHO node selection of the base station combination.
 17. The arrangement according to claim 16, comprising means for storing a tree of routes formed by the route from the network node to each of the base stations in the base station combination and means for comparing the stored tree of routes with a new tree of routes derived from information from an updated topology database.
 18. The arrangement according to claim 17, comprising means for storing the tree of routes by means of a signature or digest.
 19. The arrangement according to claim 16, wherein the means for interrupting comprises further means for updating of the pre-calculated DHO node selection for a base station combination in the database, if said new tree of routes is different from said stored tree of routes.
 20. The arrangement according to claim 16, comprising means for storing a timestamp associated with the route from the network node to each base station, wherein the timestamp indicates the last time when the route was updated.
 21. The arrangement according to claim 20, comprising means for storing a timestamp associated with each base station combination in the database, wherein the timestamp indicates the last time the DHO node selection for the base station combination was calculated.
 22. The arrangement according to claim 21, comprising means for interrupting updating of the DHO node selection for a base station combination in the database if the timestamp associated with the base station combination indicates a later time than the timestamps associated with the routes from the network node to all the base stations in the base station combination.
 23. The arrangement according to claim 12, comprising means for triggering updating of the DHO node selection for a base station combination in the database by a configuration change of the mobile communication network if it is determined that the updating will change the DHO node selection for the base station combination.
 24. The arrangement according to claim 23, comprising means for temporarily allocating more computation resources to the updating if it is determined that the updating will change the DHO node selection of the base station combination in the database.
 25. The arrangement according to claim 1, comprising means for storing a timestamp that indicates the time of the last relevant event in the mobile communication network, wherein the last relevant event is a type of events that may affect the DHO node selection of base station combinations in the database.
 26. The arrangement according to claim 25, comprising means for storing a timestamp associated with each base station combination in the database, wherein the timestamp indicates the last time the DHO node selection for the base station combination was calculated.
 27. The arrangement according to claim 26, comprising means for avoiding to use the DHO node selection of a base station combination in the database, unless the timestamp associated with the base station combination indicates a later time than said timestamp that indicates the time of the last relevant event in the mobile communication network.
 28. The arrangement according to claim 1, comprising means for time stamping a base station wherein the timestamp indicates when the last event occurred that may affect the DHO node selection of base station combinations that include said base station in the database.
 29. The arrangement according to claim 28, comprising means for storing a timestamp associated with each base station combination in the database, wherein the timestamp indicates the last time the DHO node selection for the base station combination was calculated.
 30. The arrangement according to claim 29, comprising means for avoiding to use the DHO node selection of a base station combination in the database, unless the timestamp associated with the base station combination indicates a later time than the timestamps of all the base stations in said base station combination.
 31. The arrangement according to claim 1, comprising means for temporarily disabling macro diversity functionality means after events that affect the content of the database of base station combinations.
 32. The arrangement according to claim 1, wherein the network node is a Radio Network Controller.
 33. The arrangement according to claim 1, wherein the mobile communication network is a Wideband Code Division Multiple Access (WCDMA) network or an evolved version thereof. 